With the advent of network communication standards such as FDDI, BISDN, and SONET, the day of gigabit computer communications is here, and the day of terabit communications is fast approaching. These high speed network environments demand new and powerful tools, which depend upon information from the network to assist in the network design, network management, network control functions, and network services. A crucial problem with these high speed environments is to monitor the raw data from one or more high speed communications channels and convert this data to useful “information” for a user, for a service, as an input to an algorithm whenever it is required, and so on.
Up to now, this problem has been viewed as “real-time” network monitoring and performance evaluation. Network monitoring is generally defined as extracting, processing, collecting, and presenting dynamic information with respect to the operation of a system. Monitoring information is then used by network performance management analysts to evaluate the state of network resources in real-time, usually by an individual analyzing the monitoring information on a computer display.
One of the requirements of managing large networking structures is to monitor a great number of various applications that are responsible for information transmission throughout a computer network that may include disparate platforms.
Some of these of applications are background tasks, which are commonly named as such because they generally do not offer a user interface. There is a need for behavioral information about background tasks that are responsible for information transmission among a variety of systems. In fact, an application operator needs to know whether a transmission is successful or not, and whether the transmission encountered problems or bottlenecks. Unfortunately, the background tasks do not provide any status information, and thus the application operator has no way to determine whether the application is working correctly or not.
A widely used approach to heterogeneous application transmission is message queuing. Message queuing enables distributed applications to exchange messages regardless of the hardware and software resources. In message queuing systems, the sending applications need not be concerned about the delivery routes or the timing of when the receiving applications pickup the messages. The receiving application can pick up new messages when appropriate, without necessarily maintaining a direct link with the sending application. The receiving application can also confirm receipt if required.
Messages may flow between applications synchronously or asynchronously. Synchronous mode allows the sending application to receive a reply from the receiving application before continuing. Messages can also flow between applications in a one-to-one mode, one-to-many, many-to-one, or any combination.
Generally, a message application contains two parts: the application data, and the message identification data. The message may be identified by several parameters such as the type of message, the length of the application data, and the priority level of the message.
Several ways are known to monitor message applications and their resources. Commercial products like Tivoli from Tivoli System and Omegamon from IBM Corporation allow monitoring of queues and determination of the status of the applications. With these products, the application operator must continuously navigate through a plurality of panels to find the parameters needed to take appropriate actions. While doing so, there is a risk of missing an important problem that occurs in the applications.
Other commercial products, such as the MQSeries and the CICS from IBM Corporation, provide ways to determine the depths of queues and the status of applications.
U.S. Pat. No. 5,655,081 issued to Bonnell et al. discloses a system for monitoring and managing computer resources and applications across a distributed computing environment using an intelligent autonomous agent architecture. Like the aforementioned products, this system is able to trigger an alert message when a queue contains a predetermined number of messages with no application identification.
None of today's tools, however, provides the operator with a unique interface that gathers status of the tasks and the depth of queues relevant to a specific application to be monitored. Instead, the known systems provide information on all applications in the entire system.
Therefore, there is a need to provide the application operator with a single system that gathers all the information relevant to one application and the resources being used.